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Biblioteca 3D 


Hoy nos serviremos de una 


técnica a la que llamaremos 


e 
modelado por intersecciones 


para crear los povcazas 


espaciales que ilustran el f 


presente número de 


¿Aendermgnía. Con esta técnica AS 


pe 


podremos conseguir hice Y 
” 


Similares a los que pueden 
0 


crearse desde el 3D lofter de 


3D Studio , desde el Editor de 


Formas de Imagine. 


| sistema que se em- j 
plea en los mencio- ¿ 
nados módulos de ¿ 
3D Studio e Imagi- E 
ne consiste en utili- ¿ 
zar dos o tres formas ¿ 
bidimensionales para crear una forma : 
tridimensional, correspondiendo cada ; 
una de las formas 2d empleadas al perfil: 


del objeto 3d, tal como éste puede verse al : 
seguir paralelamente la línea de alguno de : 
los ejes. En las escenas de Rendermania : 
hemos aceptado siempre —arbitrariamen- E 
te— que el “suelo” está en el plano X-Z. : 
Por lo tanto, si el objeto va a ser construi- E 
do descansando sobre dicho suelo, el eje . 
Y sería el empleado para la llamada vista a 


superior (o “top”) del objeto a crear. 


P 


Supongamos que deseamos crear la 
forma básica de un coche (que reposará 
sobre nuestro suelo X-Z.) Para nuestros 
propósitos precisaremos de tres formas 
2D para los tres perfiles del vehículo; 
uno con el perfil que presenta el mode- 
lo tal como lo vemos desde arriba (si- 
guiendo el eje Y), otro con el perfil que 
exhibe el coche cuando lo vemos de 


para cazas espaciales 


frente (vista frontal) y otro con el perfil 


lateral del modelo (vista lateral). Aquí z 
supondremos que el espectador está si- E 
tuado de modo que mira al objeto en a 
construcción a lo largo del eje Z. Por : 
tanto los ejes usados para las vistas se- : 


rá Y para la superior, Z para la frontal y 
X para la vista lateral. 


Modelado usando perfiles 


Hay muchos paquetes que disponen . 
de opciones para crear objetos a partir : 
de perfiles. Casi todos ellos funcionan E 
a base de polígonos y quizá por esta ra- : 
zón sus modeladores presentan restric- E 


ciones en cuanto a las formas 2d que 


pueden aceptarse para “alzar” los mo- a 
delos. En algunos paquetes el dibujo . 
para la vista top ha de ser siempre una E 
forma convexa, en otros, los vértices de . 
las vistas frontal y lateral deben cum- E 


plir ciertos requisitos, etc. 


En cuanto al procedimiento que si- - 
gue el modelado por perfiles, es -en , 
casi todos los programas poligonales— - 
el siguiente. Usando los vértices de las z 
vistas frontal y lateral, el algoritmo a 
marca las alturas en las que deben cre- a 
arse los vértices tridimensionales. Lue- E 
go, para cada una de estas alturas, los : 
vértices 2d del perfil top generan una E 


sección tridimensional al adaptarse al 


volumen espacial resultante de la in- : 
tersección con los vértices de los otros 


dos perfiles. 


Esta poderosa técnica de modelado E 
es la base para crear objetos cuyo dise- A 


ño resultaría bastante difícil con otros 
métodos. Pero no todos los programas 
disponen de opciones para generar ob- 
jetos con más de un perfil. Este es el 
caso de POV, de Polyray, y de otros 
programas de este tipo. Sin embargo, 
no hay que desesperar: existe un truco 
para hacer algo parecido al modelado 
de perfiles y tanto POV como Polyray 
pueden usarlo. 


La extrusión es la solución 
Los Povmaniacos más antiguos re- 
cordarán que antes de la versión 3.0, 
POV no disponía de ninguna sentencia 
que le permitiera generar objetos ex- 
truidos. Sin embargo, a pesar de esto, 


los usuarios de POV lográbamos crear : 


objetos de apariencia extruida usando 
la sentencia heightfield, normalmente 
empleada para generar mallas de apa- 
riencia montañosa. Ahora. de la misma 
manera, podemos emplear un pequeño 
truco para conseguir objetos generados 
a partir de perfiles, aunque el lenguaje 
de POV no tiene una sentencia especí- 
fica para ello. 

La idea consiste en realizar una sne- 


cilla operación de intersección entre 


dos o más objetos extruidos. Por si aún 
hay alguien que no lo sepa, se llama 
objeto extruido o extrude a un objeto 
tridimensional generado mediante el 
procedimiento de desplazar una forma 
bidimensional a lo largo de un “path” o 
camino. Ejemplos sencillos de extru- 
sión son el cubo que obtenemos al ex- 
trusionar (perdón, Real Academia de la 
lengua) un cuadrado o la letra tridi- 
mensional que conseguimos al dar pro- 
fundidad a la forma 2d de dicha letra. 
En estos ejemplos, el path empleado es 
una línea recta perpendicular al plano 
donde está dibujada la forma 2d. 

Este método llamado extrusión pue- 
de dar como resultado objetos muy 
simples o muy complejos, dependien- 
do de la forma y el path empleados. Si 
por ejemplo la forma 2d a extrusionar 
(con tu permiso otra vez Real Acade- 
mia) es un círculo y el path una línea 
enrevesada, el resultado 3d podría ser 
una cuerda. La sentencia que imple- 
menta POV para realizar extrusiones es 
Prism y la sintaxis de la misma es: 


prism ( 
[linear_sweep | conic_sweep ] 
[ Iinear_splinequadratic_splinel cubic_spline ] 
ALTURAL. 
ALTURA2, 
numero_total_de_puntos, 
<punto_1>, <punto_2>, ..., <punto_n> 
| open] 
[ sturm ] 
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Con la sentencia Prism crearemos 
objetos 3d extrusionando una o más 
formas 2d a lo largo de un eje. Estas 
formas 2d iniciales se definen mediante 
listas de puntos incluidas dentro de la 
misma sentencia y deberán ser siempre 
cerradas. POV creará la forma 2d ini- 
cial conectando los puntos definidos 
con líneas o curvas y después extrusio- 
nará (elevará, desplazará) la forma re- 
sultante a lo largo del eje Y, con lo que 
el objeto 3d final quedará paralelo al eje 
X-Z. Más adelante estudiaremos la for- 
ma en que nos afecta esta orientación. 

En la sintaxis de Prism, las palabras 
entrecorchetadas son opcionales. Las 
dos primeras se refieren al path y, por de- 
fecto, la usada por POV es linear_sweep, 


la cual da como path una línea recta : 
perpendicular al plano X-Z. (El autor a 


de estas líneas no tiene aún muy claro 
el funcionamiento de conic_sweep.) El 
siguiente parámetro a indicar controla 
el contorno de las formas 2d. Por defec- 
to la opción empleada es linear_spline, 
lo cual da como resultado que los pun- 
tos utilizados para definir la forma 2d 
se conecten con líneas rectas. Esto sig- 
nifica que el objeto final será una forma 
3d facetada y con contornos sin suavi- 
zar. Este inconveniente, no obstante, 
puede ser eludido empleando quadra- 
tic_spline o cubic_spline, que son dos 
tipos de curvas spline soportadas por 
POY para propósitos de suavizado. Co- 
mo recordaréis, los splines son curvas 
generadas por fórmula cuya forma es de- 
terminada por uno o más puntos de con- 
trol. Los splines se emplean bastante en 
los modeladores poligonales, en los cua- 


les son usados para crear paths y dibujar E 


formas 2d (para extrusionarlas luego). El 
uso de quadratic_spline o cubic_spline 
afectará además a la sintaxis anterior. 
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Los dos parámetros siguientes son 
las alturas Y donde comenzará y termi- 
nará la extrusión del objeto. Si por 
ejemplo la forma 2d es un cuadrado de 
2*2 unidades y damos los valores 3 y 5 
como alturas, el resultado 3d será un 
cubo de 2 unidades de lado que flotará a 
3 unidades de altura sobre el suelo X-Z 
(situado en Y=0). Estos valores contro- 
lan pues, la longitud de la extrusión y la 
posición final del objeto 3d. El siguien- 
te parámetro es el número total de pun- 
tos a cuyo valor, en caso de emplear 
splines, habremos de sumar los puntos 
de control usados para las curvas. 

Después viene la lista de puntos de la 
forma 2d. Como se ha dicho anterior- 
mente, si estamos empleando splines 
hay que indicar los puntos de control ne- 
cesarios. Cuadratic_spline sólo necesita 
un punto —que colocaremos al principio 
de la lista— mientras que cubic_spline ne- 
cesita dos: el primero lo pondremos al 
principio de la lista de puntos y el segun- 
do al final de la misma. En cuanto a estos 
puntos de control, el autor de las presen- 


tes líneas reconoce que no sabe predecir 
la manera en que determinan la forma 
de la curva, debiendo poner los valores 
a ojo en cada prueba. (Normalmente lo 
mejor es emplear valores pequeños y 
cercanos a <0,0> para que las curvas no 
sean muy exageradas). 

Además, la lista de puntos incluida 
en Prism puede describir varias formas 
2d y en caso de que las siguientes estén 
inscritas dentro de la primera forma 2d, 
se producirán restas CSG en la misma. 
También hay que recordar que cada una 
de estas formas —llamadas subprismas 
en la documentación de POV— debe es- 
tar cerrada, Esto lo lograremos repitien- 
do al final el primer punto del subpris- 
ma. En cuanto a los puntos propiamente 
dichos, deben ser colocados siguiendo 
un orden determinado. 

La siguiente palabra, open, es opcio- 
nal y elimina las tapas superior e inferior 
del objeto extruido, dejándolo hueco. Na- 
turalmente el uso de open impide efec- 
tuar posteriores operaciones CSG sobre 
el objeto, ya que este no tendrá un volu- 


'— 


Dc A 


En las dos imágenes 
de esta doble página 
se aprecia como el 


cruce de la sección 
del peón produce este 
resultado con 
cubic_spline. 


men interno con el que operar. Final- 
, Si estamos empleando splines 


cubic y la visualización es incorrecta, 
emos incluir la palabra sturm, que 


0 
4 


mplear el método. 
i 


¿ 


er r sumido 


más novato: ER , estado de lees sespe- E 
ración guey el uso de prism : 
es sencillo. Lo primero que debemos : 
hacer es crear la lista 4 coordenadas ; 
con la f As Para ello es impresci- : 


dible di A rp eviar nte dicha forma 


servirá pa tomar nota de las coorde- 


y oregllel número de puntos y las al- 


prueba. Para dicha prueba, lo mejor se- 


cambiará el algoritmo de cálculo para : 
1 Sturmian, más : 


los lectores : 


sito cuadriculado, lo que nos : 


24m, emos en la lista E 
x ig iendo un orden determinado. Una E 
y "4 vez conc luida la 1 lista añadiremos los E 


turas y hecho todo esto estaremos en ¿ 
- condiciones de visualizar la primera ¿ 


rá colocar la cámara situándola en las 
coordenadas X-Z del centro de grave- 
dad de la forma 2d y a una altura Y ade- 
cuada. (A esta posición de prueba para 
la cámara la llamaremos cámara top y la 
usaremos para comprobar la corrección 
del prism empleado.) Después entoca- 
remos la cámara apuntándola al centro 
del objeto extrusionado y listo. (Bueno, 
tambien es conveniente agregar la pala- 
bra “orthographic” al final de la declara- 
ción de la cámara para que no nos con- 
funda la perspectiva.) Como siempre, lo 
mejor para saber utilizar algo es hacer 
muchas pruebas. Los lectores que des- 
conozcan el tema pueden experimentar 
con los sencillos ficheros-ejemplo de 
POV o con el ejemplo del peón o de los 
modelos de cazas que estudiaremos 
unas líneas más abajo. 


Modelado por intersección 
de perfiles 

La noción de modelado por perfiles 
es muy simple una vez que se com- 
prende lo que es la extrusión. Como 


sabemos, hay objetos que pueden cons- 
truirse a partir de un único perfil. La ex- 
trusión de un cuadrado puede originar 
una caja, la de un círculo nos dará un ci- 
lindro, etc. (En todos estos ejemplos, el 
path debe ser una línea recta perpendi- 
cular a la forma). En POV todos estos 
objetos pueden crearse a partir de una 
sentencia prism senciJla pero ahora avan- 
cemos al siguiente nivel de complejidad. 

Este lo forman los objetos que re- 
quieren dos perfiles para ser generados. 
Es el caso de las botellas. los peones de 
ajedrez. etc. Cada uno de estos objetos 
presenta el mismo perfil tanto frontal 
como lateralmente. De nuevo POV 
puede crear objetos de este tipo ya que 
cuando ambos perfiles son iguales, el 
objeto puede crearse como una superfi- 
cie de revolución. ¿Pero y si el objeto 
tiene dos perfiles diferentes? 

Este puede ser el caso de un coche 
(MUY sencillito) o del mismísimo ra- 
tón de nuestro ordenador. En el caso del 
ratón, por ejemplo, necesitaremos un 
vista superior y otra lateral (con la que 
obtendremos la curvatura con la que el 
ratón se adapta a la mano.) Ya hemos 
dicho antes que POV no dispone de nin- 
guna sentencia que permita construir un 
objeto a partir de dos o más perfiles. 
¿Qué hacer entonces? La respuesta es: 

|) Crear un objeto extrusionado para 
cada perfil. 

2) Rotar y situar adecuadamente los 
objetos extrusionados con vistas a la 
Operación 3. 

3) Crear un objeto CSG como resul- 
tado de la intersección de los objetos 
extrusionados. 

Recordemos que en una operación 
CSG de intersección entre dos o más 
objetos, el resultado es siempre un ob- 
jeto cuyo volumen espacial era el que 
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compartían todos los objetos implica 
dos en la operación. Por ello también 
podríamos llamar a este truco “modela- 
. En fin, realmente 
esta técnica no produce exactamente los 


do por volúmenes” 


mismos resultados que pueden esperar- 
se del Fit de 3D Studio o del Editor de 
Formas de Imagine (y que nos perdo- 
nen todos los usuarios de otros progra- 
mas que también permiten modelado de 
perfiles: no es cuestión de presentar una 
lista completa). Sin embargo, por el 
momento, es lo más aproximado a ello 
que podemos lograr con POV. 

Para intentar comprender las parti- 
cularidades de lo que hemos llamado 
modelado por intersección, estudiemos 
un par de casos. Supongamos que que- 
remos crear el modelo de un juguete: 
un cochecito de madera sumamente 
sencillo que sólo precisa emplear dos 
perfiles, el superior y el lateral (ruedas 
y volante aparte, claro). Para ello extru- 
sionaremos los perfiles superior y late- 
ral del cochecito y, después de orien- 
tarlos y situarlos adecuadamente. 
crearemos el cochecito con una opera- 
ción de intersección entre ambos obje- 
tos extrude. Esto no parece revestir di- 
ficultades, Pero veamos otro caso más 
complejo. Supongamos ahora que que- 
remos crear un peón de ajedrez desde 
POV usando esta técnica. (Sería una 
tontería ya que disponemos de Sor, pe- 
ro es un buen ejemplo.) Dibujaremos el 
perfil del objeto y escribiremos la lista 
de puntos correspondiente en una sen- 
tencia Prism. Como este perfil corres- 
ponde tanto a la vista frontal como a la 
lateral del peón, lo mejor será utilizar 
un *declare para poder referenciar dos 
veces el prism declarado. Acto segui- 
do crearemos el objeto extrude. Si ob- 


servamos el objeto con la cámara de 
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Vistas superior, ¡aterai (del 
centro de la nave), frontal y 
lateral (de los lados) de la nave. 


prueba top descrita anteriormente apre- 
ciaremos el perfil del peón, si sus pun- 
tos se han escrito correctamente. Si se 
aprecian fallos graves en la forma, la 
causa estará casi con toda seguridad en 
algún error de la lista de puntos o bien 
de un fallo en la predicción de las cur- 
vas splines, si las hay. 

El siguiente paso será colocar el ob- 
jeto extruido en la orientación necesa- 
ria, o sea, en este caso, con la base del 
peón descansando en el suelo X-Z. Pa- 
ra ello efectuaremos una rotación de 90 
grados en el eje X para el objeto. De 
esta manera obtendremos el perfil fron- 
tal para la intersección. Si hemos dado 
las coordenadas de los puntos con astu- 


cia, de modo que los puntos correspon- 
dientes a la base del perfil estén en 
Z20, ni siquiera tendremos que despla- 
zar la forma extrusionada para colocar- 
la sobre el suelo. 

Ahora vamos a por el perfil restante. 
Crearemos un nuevo objeto con el mis- 
mo perfil pero esta vez efectuaremos dos 
rotaciones. La primera, en el eje X. ser- 
virá como antes para dejar el nuevo per- 
fil con la base en el suelo y la siguiente, 
de 90 grados en el eje Y, nos servirá para 
Obtener la vista lateral del objeto. Se en- 
tiende que para que esto último funcione, 
la forma 2d inicial del peón habrá de de- 
finirse centrada en el eje Z. De no ser así 
habremos de efectuar maniobras super- 
fluas de traslación, a fin de superponer 
adecuadamente ambos objetos. 

El último paso es muy sencillo. Usan- 
do ambos objetos crearemos el peón 


realizando una intersección entre am- 
bas formas. Podéis ver el resultado de 
todo esto en las fotos (y realizar vues- 
tras propias pruebas con peon.pov). 
Como veis el objeto resultante, aunque 
interesante, no es exactamente un peón. 
¿Por qué? (El autor de estas líneas re- 
conoce que, al principio, pensaba que 
el fruto de estas operaciones sería un 
peón.) La respuesta está en el hecho de 
que estamos ante una operación boolea- 
na (AND) entre los volúmenes espacia- 
les de dos objetos-perfil idénticos. En 
ella cada objeto-perfil se extiende a lo 
largo de un path cuya longitud ha de ser 
en este caso el ancho del peón. Al prin- 
cipio es difícil comprender lo sucedido 
pero basta con examinar atentamente 
las fotos para entender el principio. La 
técnica requiere cierta capacidad de 
imaginación espacial ya que habremos 


-mentalmente- de descomponer el ob- 
jeto deseado en sus perfiles antes de dar 
un solo paso. Por otro lado, como aca- 
bamos de ver, no podremos conseguir 
cualquier forma. Con otros modelos, 
en cambio, la intersección de volúme- 
nes funcionará muy bien —¿recordáis 
las almenas de los castillos del número 
1?- Veamos otro caso: la construcción 
de un caza espacial. 


¿Cazas espaciales? 

Podría parecer que debe haber pocas 
cosas que requieran menos reglas que 
el diseño de naves espaciales futuristas. 
A fin de cuentas el artista puede dibu- 
jarlas tal y como le de la gana, sin que 
nadie pueda chistarle, pues no existen 
proporciones ni modelos de compara- 
ción fuera de las ilustraciones de SF. 

(Nota del Redactor Jefe: José Ma- 


nuel Muñóz desapareció misteriosa- 
mente mientras estaba preparando este 
artículo. Días más tarde volvió a apa- 
recer por la redacción y manifesto que. 
en el momento de hallarse sumido en 
la elaboración de las líneas preceden- 
tes, fue raptado por entidades extrate- 
rrestres y llevado a un sitio indetermi- 
nado fuera de nuestro planeta. Al 
parecer estas entidades habían capta- 
do las furiosas emanaciones mentales 
de este articulista, el cual se hallaba 
desesperado porque no conseguía ima- 
ginar una sola nave espacial decente. 
Ansiosas de ayudarle, las entidades le 
mostraron sus naves espaciales por 
dentro y por fuera sólo para ver, atóni- 
tas, como José Manuel Muñóz recha- 
zaba de plano sus diseños aduciendo 
que no podía presentar en Renderma- 
nía modelos tan ridículos y simplones. 
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Las mencionadas entidades extrapla- 
netarias se enfurecieron entonces mu- 
chísimo ante este rechazo a miles de 
años de adelantos tecnológicos, y pro- 
cedieron a llevar a cabo diversos expe- 
rimentos con el cerebro de JM.M.P 
tras lo cual le liberaron dejándole en 
un estado lamentable. Por esta razón 


Pruebas de iluminación. 


no podemos garantizar la validez del 
resto del presente artículo.) 

Por ejemplo, el artista puede imagi- 
nar que su nave emplea los medios co- 
nocidos de propulsión y dibujar cohetes. 
O bien puede decidir que la nave utiliza 
la presión de la luz y optar por un velero 
solar. Incluso puede aducir que su crea- 
ción emplea la energía de la improbabi- 
lidad —igual que la “Corazón de Oro” de 
“Guía del autoestopista galáctico”— y 
dibujar una nave rodeada por monos 
escribiendo las obras de Shakespeare. 
La libertad es total. 

Sin embargo a la hora de la verdad la 
cosa no es tan sencilla. El caso es que el 
artista desea que su obra parezca una 
nave espacial futurista y... ¿cómo pue- 
de lograrlo si no hay un modelo en el 
que basarse? Si se basa demasiado en 
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los cohetes actuales. el resultado no pa- 


recerá demasiado avanzado tecnológi- 
camente hablando y si se usa demasiado 
la imaginación el resultado puede aca- 
bar pareciendo cualquier cosa menos 
una nave espacial. El problema puede 
agudizarse si queremos crear un tipo es- 
pacial de nave, por ejemplo un caza. Un 
caza espacial no necesita alas pero si no 
se las ponemos es probable que el mo- 
delo no nos parezca un caza. Tampoco 
debería necesitar una cabina de cristal 
como las de los cazas terrestres, ya que 
en el espacio profundo los objetos que 
no emiten luz no son visibles (excepto 
por el hecho de que ocultan las estrellas. 
por supuesto). Pero, de nuevo, el hecho 
de poner una cabina nos hará creer que 
el caza tiene unas dimensiones reduci- 
das, tal como el espectador espera. 


Hroki1 


Este es el nombre de nuestro caza. 
La estructura principal del mismo está 
fuertemente basada en la de un coche 
deportivo que sirvió como modelo; 
—como se ha dicho antes, cualquier co- 
sa puede servir de inspiración para 
crear un caza espacial: el autor vio en 
cierta ocasión una nave sumamente pa- 
recida a un WC con alitas y reactores 
varios—. Si el lector examina las fotos 
con las formas a extrusionar y la se- 
cuencia de construcción comprenderá 
enseguida como se ha llegado al resul- 
tado final. 

En el caza hay dos cuerpos principa- 
les: el central. que requirió tres formas 
extrude (para los planos superior. fron- 
tal y lateral) y el lateral, en el que se 
usó un perfil distinto. Aquí el mayor 
problema fue encajar estas dos piezas 
lo cual (¡Ay!) no se resolvió demasiado 
bien ya que no se consiguió una transi- 
ción suave. Luego se empleó otra inter- 
sección de extrudes para la cabina y se 
añadieron los propulsores (hechos con 
Sor) y las alas (más extrusión.) Espe- 
remos que, con más experiencia, los 
próximos modelos creados con esta 
técnica resulten mejor. 
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En el número 46 de Pcmanía asistimos a una pequeña comparativa entre 
dos de los mejores modeladores existentes para raytracers: Moray y Breeze. 


El primero, funcionando bajo el arcaico MS Dos, es ya un viejo conocido de 


muchos de nuestros lectores Breeze, en cambio, es un programa casi 


desconocido en est 


cómodo 


interface. Hoy pre 
para intentar responde 


Breeze d 
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os rendermaniacos : 


más antiguos cono- 
cen la reticencia del 


autor de estas líneas E 
a emplear modela- A 
dores. Las razones , 
son múltiples aunque difíciles de expli- a 
car. La mayoría de los trazadores de ra- - 
yos construyen sus universos virtuales : 


mediante objetos generados con fórmu- 


las, no con polígonos. Este es el caso de , 


POYV, Polyray, Vivid, Magic Camera y 


muchos raytracers más. Estos objetos : 
generados a base de fórmulas implican ¿ 
un procesamiento visual más lento que a 
en el caso de los objetos generados por E 
polígonos y por esta razón los programas E 
mencionados no incorporan un modela- a 


dor interno para diseñar las escenas. En 
lugar de esto, como sabemos, estos pro- 


gramas requieren del empleo de editores a 
de texto para dicha tarea. Editores con ; 
los que escribimos ficheros fuente com- . 
puestos por las sentencias permitidas por , 


el lenguaje escénico de cada programa. 


Problemas de los 
modeladores 

El caso es que el empleo de un buen 
modelador suele ser más rápido e intui- 
tivo que el de cualquier lenguaje escé- 


nico. Además hay muchos usuarios que : 
no quieren “programar” escenas. Para : 


ellos hay cuatro posibles opciones: 


A) Crear la escena con un modelador E 
comercial potente y usar una utilidad de : 


conversión para “traducir” el fichero del 
modelador al formato escénico del ray- 
tracer y poder generar la escena con él. 

B) Usar alguno de los modeladores 


—de coste bajo o nulo— desarrollados E 


para estos raytracers. 
C) ¡Aprender el lenguaje escénico! 
D) Prescindir de POV, Polyray, etc. 
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Como mucha gente no está dispuesta 
a pasar por C. no disponen de A y no 
quieren llegar a D, la única opción res- 
tante es B. Pero los modeladores de la 
opción B no tienen la misma orientación 
ni potencia que los de A. Los modela- 
dores de bajo costo como Moray o Bre- 
eze (aquí los llamaremos modeladores- 
B) han sido creados expresamente para 
trabajar con POV y otros raytracers. Tra- 
bajan mediante un sistema de ventanas y 
visualizan polígonos como los modela- 
dores comerciales pero ahí se acaba el 
parecido. Programas como Moray y 
Breeze utilizan las mismas primitivas 
disponibles en los lenguajes escénicos 
pero empleando objetos poligonales en 
las ventanas de trabajo. Al acabar la se- 
sión, sin embargo, los objetos poligona- 
les deben ser “traducidos” a sentencias 
del lenguaje escénico para que el raytra- 
cer empleado pueda generar la escena 
creada desde el modelador. Esto implica 
los siguientes problemas: 

1) Las fórmulas necesarias para resol- 
ver las operaciones CSG no son idénticas 
paralos objetos poligonales y los genera- 
dos por fórmula y son muy complejas. 
Hasta ahora ello ha significado que los 
objetos CSG no se visualizan adecuada- 
mente en las ventanas de trabajo de mo- 
deladores como Moray y Breeze. 

2) Los modeladores-B van siempre 
a remolque de las versiones nuevas de 
los trazadores de rayos. 


3) Existen muchas primitivas que no 
se visualizan correctamente en la mayo- 
ría de los modeladores-B. Este es el caso 
de los objetos blob y los heightfields. 

4) El trabajo con los modeladores-B 
no es demasiado ágil ya que el motor de 
render está fuera. Por tanto o bien hay 
que llamar al raytracer desde el mode- 
lador o bien hay que salir de éste y eje- 
cutar la escena exportada con el raytra- 
cer para, después, retomar al modelador. 

5) El uso de uno de estos modelado- 
res no implica que podamos olvidarnos 
del lenguaje escénico ya que muchas 
de las posibilidades del raytracer deben 
ser controladas —aunque se ordenen 
desde el modelador— con conocimiento 
de los efectos de dichas sentencias. Por 
ejemplo la niebla, la atmósfera, etc. 

6) Las sentencias de programación 
-if, while... de POV—, algunas funciones, 
etc., deben usarse fuera del modelador. 

Sin embargo, a pesar de todos estos 
inconvenientes, los modeladores segui- 
rán siendo usados por aquellos que 
quieran crear modelos concretos para 
sus escenas o que, sencillamente, odien 
la “programación escénica”. 


La nueva beta de Breeze 

En el número 46 de Pcmanía exami- 
namos la versión 2.0 Beta de Breeze y la 
que hoy comentamos sigue siendo una 
beta -aunque distinta- de la misma ver- 
sión. Breeze, programado por Neville 
Richards tiene una serie de característi- 
cas entre las que destaca el soporte de 
OpenGL y la librería de render 3DR de 
Intel. En concreto el uso de OpenGL nos 
permitirá visualizar modelos sombrea- 
dos y texturas aplicadas en objetos desde 
las ventanas de Breeze sin necesidad de 
invocar al raytracer. Esta posibilidad es, 
junto con la sencillez de manejo del 


< 


programa y la ayuda, quiza lo más atrac- 
tivo del programa pero, por ahora, sigue 
sin resolverse el tema de la visualización 
de las diferencias e intersecciones CSG. 

En la nueva versión Neville declara 
haber arreglado algunos fallos y haber 
implementado soporte para exportación 
de escenas en VRML y RenderMan. 
Aparte de esto, Breeze ya soportaba im- 
portación de ficheros 3DS y DXF, agru- 
paciones de objetos, llamada a POV sin 
abandonar el programa. superficies de 
revolución y extrusión, etc. El progra- 
ma -que no incluimos aquí por tratarse 
aún de una beta- tendrá en sus futuras 
versiones un sistema de render por Red 
con el cual será posible utilizar un gru- 
po de ordenadores para ejecutar un ren- 
der o una animación y extensiones para 
el macrolenguaje (¿?). En resumen: po- 
cos cambios entre las dos betas. 


La versión 2.5 de Moray 

Ya que Moray ha sufrido más cam- 
bios que Breeze vamos a dedicarle algo 
más de espacio. La instalación resulta 
muy sencilla. Basta con descomprimir 
el fichero zip en un directorio específi- 
camente creado para Moray y ejecutar 
el setup. Al descomprimir se crearán 
una serie de subdirectorios dentro del 
nuestro donde se guardarán las utilida- 
des, los ejemplos, etc. Es muy impor- 
tante no olvidar poner los paths adecua- 
dos para llamar al render y referenciar a 
los ficheros de inclusión del render. Si 
no lo hacemos así u olvidamos pulsar 
F9 para grabar el setup podemos volver- 
nos locos intentando averiguar por qué 
fallan las Hamadas al render. 

En esta nueva versión de Moray, sus 
autores han incluido soporte para todas 
o casi todas las nuevas características 
de POV 3.0. Claro que esto quiere decir 


en muchos casos que se han incluido 
menús para controlar opciones de POV, 
no que Moray realice cálculos propios. 
Tal es el caso de la atmósfera, la nie- 
bla. la radiosidad, etc. Por otro tado 
Moray sigue siendo un programa de 
DOS —que funciona en modo protegido 
bajo Vesa—, pero no por mucho tiempo. 
En los mismos ficheros de la actual 


versión ya se anuncia que la próxima ; 


será un programa de 32 bits para Win- 


dows 95 y NT. ¿Se incluirá visualiza- 


ción flat en dicha versión? Esperemos : 


que sí. Por ahora éstas son algunas de 
las mejoras de la última versión: 
-Soporte para objetos blob y Super- 
ellipsoid. 
-Soporte para las nuevas posibilida- 
des de la cámara. 


-Soporte para los nuevos objetos de : 


revolución y extrusión. 
-Mejorado el soporte a Polyray 
-Posibilidad de Hamar directamente al 
Render, en máquinas de mucha memoria. (¿?) 
-Mejoras en la edición de objetos. 


-Mejoras en el redibujado de objetos. 
-Código para visualizar objetos CSG. 
(Según afirman, aún no muy fiable). 
“Posibilidad de ver bitmaps como fondo. 
Quizá lo peor de Moray sea que su in- 
terface, aunque rápido y eficaz, es, en al- 
gunas pantallas, bastante hoso y poco 1n- 
tuitivo: uno llega a asustarse de la 
cantidad de opciones que tienen algunas 
ventanas. En cuanto al botón de render, 
sigue siendo más práctico abandonar el 
programa y ejecutar el render desde fue- 
ra ya que la cantidad de memoria nece- 
saria es ridículamente prohibitiva; en una 
escena sencilla ejecutada en un ordena- 
dor con 64 megas de Ram. la llamada di- 
recta a POV implicó un inacabable ron- 
roneo del disco duro durante media hora 
mientras la misma escena ejecutada ex- 
teriormente requirió menos de un minu- 
to. También hay que decir que el fichero 
moray.ini de configuración admite de- 
masiados comandos. Sólo su explicación 
ya requeriría varias páginas (aunque por 
otra parte también es posible que no ne- 
cesitemos tocarlos). Todo esto no ha 
cambiado desde la versión anterior. 


En resumen 

No es probable que los usuarios ex- 
perimentados que antes no usaran mo- 
delador cambien su filosofía por culpa 
de estas nuevas versiones. Por otro tado 
no hay que confiar demasiado en cam- 
bios revolucionarios (en lo que se refie- 
re a la visualización) para la próxima 
versión de Breeze. Pero quizá si podría 
haberlos en la de Moray, ya que el paso 
de Dos a Windows implica muchos 
cambios en la gestión de memoria (op- 
timización de llamadas directas) y en la 
visualización (¿OpenGL? ¿Direct3D?). 
Por ahora, en nuestra opinión, Moray 
sigue siendo la mejor opción. 
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La Portada 


Caza estelar Hroki 


Un solitario caza estelar Hroki 


a aguarda, oculto en el cent 


nebulosa donde se escont su 
base, la aparición de al. 
desprevenido mercante pro 
de un dercano agujero de 
Naturalmente tablón rí 
2. srt 


yA - E . e 
aparecgr una flota imperial 
' > 


Mo 


dispuesta a limpidr el sector de y 
Pa 7 


piratas. Pero esto ya ha-ocurrido 
antes y nuestro caza HroWÍ auhque 
ya algo anticuado, confía en la 
potencia de su motor trucado 
—pero imprevisible— que le 
convierte en uno de los montones 
de basura más rápidos de la 
galaxia, con permiso del Halcón 


Milenario, por supuesto. 
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modelo LG-700 


l menos esto es lo 
que diría el autor de 
esta nave, y nadie 
puede demostrar lo 
contrario. ¿Quién 
puede afirmar que, 
en algún lejano sistema estelar, no existe 


una nave como ésta? ¿Y por qué dicha na- 
ve no podría disponer del más moderno 
condensador de fluzo, de un exprimidor 
de protones ultracorto, de un recargador 
de ñazos y de un colector de...? En fin, 
en un Space Opera todo está permitido. 
Los motores hacen ruido en el vacío del 
espacio y las naves son perfectamente vi- 
sibles en el espacio profundo. Incluso en 
obras más rigurosas, el tema espacial se 
permite una fantasía (en los diseños) que 
no solemos encontrar en otros campos y 
por ello los ilustradores tienen las manos 
mucho más libres para trabajar. 


Portadas posibles 

Desde que el autor de estas líneas tu- 
vo ucasión de ver aquel magnífico fon- 
do estelar de Felix Higueras Joma, la 
idea de preparar alguna portada con 
fondos estelares hechos con POV quedó 
decidida. Los pormenores de la cons- 
trucción de la nave empleada en la por- 
tada de hoy ya han sido desvelados en 
las páginas anteriores pero la idea ini- 
cial era diseñar un gigantesco crucero 
espacial. Para ello se podrían haber usa- 


do las sentencias de programación de 
POV para crear un modelo compuesto 
por cientos de objetos menores dispues- 
tos en jerarquías, tal como se hizo en el 
número dedicado a la construcción de 
castillos medievales, pero la magnitud 
del proyecto pronto resultó excesiva pa- 
ra el tiempo disponible. Para empezar 
no se deseaba construir escenas que re- 
quiriesen un consumo de memoria ex- 
cesivo, como en el caso de los castillos, 
y además existían otras dificultades: es 
difícil hacer comprender al espectador 
el tamaño de un objeto si no hay otros 
objetos con los que compararlo. Lo ide- 
al sería incluir escuadrones de cazas a 
diferentes distancias y poner algunos 
cerca del crucero para demostrar el 
enorme tamaño de éste. Todo esto ya 
implicaba la creación de otro modelo 
cuyos requisitos de desarrollo eran di- 
ferentes a los del crucero. Así pues se 
optó por crear un caza estelar y cons- 
truir la escena en torno a él. 

Aquí también había jugosas posibili- 
dades entre las que elegir. Una idea —ya 
bastante exprimida pero siempre atrac- 
tiva— fue crear un campo de asteroides 
donde aparecieran varias naves luchan- 
do. Esto requería básicamente dos co- 
sas: la primera, por supuesto, un con- 
junto de objetos-asteroide y la segunda 
una manera de colocar espacialmente a 
los mismos. Los asteroides pueden con- 
seguirse de varias maneras distintas. 
Quizá la mejor sea emplear alguna uti- 
lidad de fractalización de objetos a fin 
de conseguir la forma irregular y capri- 
chosa de estos objetos. Estas utilidades 
funcionan del siguiente modo: toman la 
geometría de un objeto inicial simple 
como un cubo o una esfera y aumentan 
su nivel de detalle paso a paso. Con ca- 
da paso desplazan también sus vértices 


El fondo estelar de nuestra 
portada. 


Una prueba con halos glowing. 


Aquí puede apreciarse lo que 
sucede cuando chocan los 
colores de estrellas y nebulosas. 


al azar con lo que el objeto va tomando 
una forma irregular. Un valor pequeño 
de “ruido” da a los objetos una aparien- 
cia gastada. sin cambiar demasiado su 
forma, mientras que un valor mayor en 
dicho factor produce objetos muy irre- 
gulares. El primer inconveniente que tie- 
ne esto para nosotros es que estas utili- 
dades trabajan con objetos poligonales. 
Por supuesto, es posible, si conocemos 
el formato ascii que acepta la utilidad (si 
es que éste es el caso). que podamos de- 
finir nosotros mismos el objeto pero es- 
to puede ser tedioso. Afortunadamente 
existen utilidades freeware como Frgen 
de Steve Anger -que Pemanía ya publi- 
có- que pueden servimos. 

Frgen tiene varios ficheritos ascii de 
ejemplo donde se describen cubos, esfe- 
ras, etc. Freen puede crear. partiendo de 
estos objetos simples iniciales. objetos 
irregulares. De un cubo podemos obte- 
ner un cubo de hielo o un asteroide y de 
una esfera un planetoide. Frgen puede, 
asimismo, grabar los objetos obtenidos 
en el formato de POV o en el de Polyray. 
Una vez en POV, después de importar el 
objeto, podremos escalarlo y cambiar sus 
dimensiones. El único problema es que 
Frgen no calcula las normales del objeto 
creado, lo cual quiere decir que la apa- 
riencia del mismo será facetada. Claro 
que también podemos emplear otra utihi- 
dad para calcular estas normales. 

De todos modos la idea del campo 
de asteroides fue también rechazada 
debido a consideraciones de memoria. 
Si queremos conseguir un campo de 
asteroides realista, hay que usar doce- 
nas -o mejor cientos— de objetos poli- 
gonales de todos los tamaños. La colo- 
cación de estos objetos es sencilla, 
gracias a las nuevas sentencias de pro- 
gramación de POV. Podemos disponer 
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a! La Portada 


Un ejemplo perfecto de 


todos los fallos que 
pueden cometerse. 


que los objetos se distribuyan de manera 
aleatoria (con rand) por un volumen es- 
pacial determinado. Aún en caso de que 
uno o más objetos se superpongan (lo 
cual no tiene por qué suceder si la densi- 
dad de objetos no es excesiva), ello no 
tiene que quedar mal. ya que estaríamos 
trabajando con asteroides, los cuales 
pueden tener cualquier forma. Este mé- 
todo de colocación 3d de objetos sólo su- 
pone un pequeño paso más con respecto 
al que ya usamos en los números O y 1 
de Rendermanía, para colocar casas y 
soldados y es el que hemos empleado 
para la distribución estelar de la portada. 


La textura estelar 

Una vez descartados los asteroides, 
por ahora, la idea final fue la que podéis 
ver en la portada del presente número. 
La escena emplea tres elementos como 
fondo: una textura estelar, un campo de 
estrellas-halo y un par de nebulosas 
también creadas con halos. El fondo de 
estrellas más pequeñas (los puntos) no 
es más que una textura de granito que in- 


. 


cluye un mapa de colores. POV incluye 
un fichero llamado Stars.inc, donde hay 
definidas varias texturas de este tipo. La 
“densidad estelar” de estas texturas os- 
cila desde el poco denso Starfield! hasta 
el máximo Starfield6. Nosotros hemos 
empleado Starfield3 colocando la textura 
sobre un plano Z al que ta cámara enfoca 
perpendicularmente. 


El cúmulo estelar 

La textura anterior sólo proporcionó 
un fondo de puntos que apenas servía 
como fondo para nuestro caza. Era pre- 
ciso añadir estrellas más cercanas o de 
mayor tamaño. Esto fue posible gracias 
a la sentencia Halo cuyo análisis ya in- 
cluimos en el número anterior de Ren- 
dermania. Como recordaréis los halos 
no son más que texturas que simulan 
una distribución de partículas dentro de 
un objeto que sirve como contenedor. 
Estas partículas pueden absorber o 
emitir luz y de hecho nuestro cúmulo 
será visible aunque desactivemos las 
luces de la escena. Las estrellas fueron 


Un experimento más. 


creadas con halos de emisión, ya que 
este tipo pareció el más adecuado para 
lograr la apariencia deseada. Al menos 
así parece deducirse de las pruebasrea- 
lizadas con los otros tipos dehalos, 
Siguiendo el ejemplo dado por Félix, 
aquí empleamosdos halos para cada es- 
trella; en la'primera se genera el tenue 
halo luminoso que se éxtiende fuera de 
la estrella y en la segunda se genera la 
estrella-halo propiamente dicha. Laides 
inicial era colocar cientos de estrellas en 
el fondo, de hecho el contador “numso- 
les” está inicializado a 200. Pero pronto 
se comprobó que un número excesivo de 
estrellas de este tipo no daba un buen re- 
sultado. debido al modo en que éstas in- 
teractuaban con las nebulosas del fondo 
(aquí esdonde Pads comprobar la dife- 
rencia entre el so de uno u otro tipo de 
halo). Estudiando la escena de Felix 
“omprobaremos que el autor colocó las 
estrellas manualmente y con cuidado pa- 
ra que éstas ao se superpusieran a las ne- 
bulosas, con Ju cual se evita este proble- 
ma. Esto sin embargo puede ser tedioso 


MA E $ 


(sobre todo si uno está cambiando la : 
cámara con frecuencia), y por ello se : 


optó por la distribución al azar. 
Porta53.pov emplea mucho la sen- 


tencia rand para dar valores aleatorios a : 


las variables que se emplean para posi- 
cionar a las estrellas y para decidir su 
color. Por ello puede suceder que mu- 
chas escenas no sean útiles al presen- 
tar fallos visuales, ya que es imposible 


predecir si el paisaje estelar va a estar E 


en armonía con el fondo de la nebulo- 


sa. En estos casos bastará con cambiar : 


el valor S de la semilla del generador. 
Los fallos mencionados consisten en 

que el halo de emisión de las estrellas 

“choca” con el fondo de las nebulosas. 


Siendo más exactos: lo que sucede es E 
que la nebulosa puede hacer visible a la . 


esfera contenedora más externa de la es- 


trella, Es un fallo que no siempre resulta E 


evidente pero que puede ocurrir, sobre 


todo si empleamos nebulosas cuyo color; 


sea demasiado diferente al de la estrellas. 

Examinemos las líneas de portaS3.pov 
que ge oran el cúmulo estelar. En pri- 
mer lugar se crea una semilla para el 
generador de números aleatorios usa- 
do para decidir el color de las estrellas 


y situarlas en el espacio. Esta semilla : 


es muy útil ya que-cambiándola podre- 


mos generar un paisaje estelar distinto : 
y asimismo, si no ños gusta el nuevo E 
paisaje. podremos recuperar el antiguo E 
simplemente volviendo a poner el valor : 
de seilla que lo genera. La siguiente ; 
variable es el contador que emplea el a 
buclé Hhwhile para crear las estrellas. La ¿ 


definición de éstas se realiza dentro del 


bucle y su colocación se decide con las E 


Operaciones. ... 

declare px=únt(rard(S)*1000)-500) 
Hdeclaxe py=(Int(raud(S)*1000)-500) 
tideclare pz=(int(rand(S)*1000)-500) 


Diferentes pruebas de texturas 


aplicadas a nuestro caza. 


Estas operaciones nos darán una po- 
sición aleatoria <px, Py, pz>, compren- 
dida entre la zona espacial definida por 
<-500, -500, -500> y <500, 500, 500>. 
En cuanto al color de la estrella se de- 
cidirá según el valor aleatorio deposita- 
do en la variable col. Según sea éste, 
las variables r, g, b, 12, g2 y b2 tomarán 
valores de color que se usarán en los 
dos halos de la estrella. 


Nebulosas 

Las dos nebulosas empleadas en la es- 
cena están colocadas dentro de grandes 
esferas de cientos de unidades de diáme- 
tro centradas en el eje de coordenadas. 
Como tanto el caza como la cámara es- 
tán muy cerca de esta posición, el resul- 
tado es que la “foto” está tomada desde 
dentro de la nebulosa. Las estrellas pue- 
den quedar dentro o fuera de este radio. 
Un detalle que tiene su importancia ya 
que parece que sólo las estrellas que ca- 
en dentro del volumen espacial de las ne- 
bulosas pueden presentar fallos graves 
de visibilidad (las otras, aparecerán más 
difuminadas, lo cual parece natural en el 
paisaje interno de una nebulosa.) 

Para crear escenarios estelares dife- 
rentes podemos cambiar los valores tur- 
bulence de los halos, la escala de los ob- 
jetos contenedores y la orientación de 
los mismos. El resultado de cada uno 
de estos cambios es imprevisible a prio- 
ri pero afortunadamente el tiempo de 
generación no es excesivo, lo cual nos 
deja bastante tiempo para hacer prue- 
bas. Otra idea interesante sería colocar 
las estrellas de otro modo, con un valor 
de distribución menor en un eje, a fin 
de conseguir un plano galáctico (mayor 
densidad estelar). También podríamos 
haber colocado una o dos estrellas real- 
mente grandes, un planetoide, etc. 
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El Foro del lector 


Visita a un Museo virtual 


Hoy descargamos nuestro 
buffer de misivas. Los lectores 
envían escenas y animaciones 
de Objetos extraños, naves, 
ritos satánicos, plataformas 
marítimas, chicas manga en 3d, 
aviones y muchas creaciones 
virtuales más, creadas con 


diversos programas. Sólo para 


Tomas Garralaga Camarero también se ha subido al tren de 
POY y nos envía unas primeras imágenes bastante resultonas en- 
tre las que destaca la sencilla pero hermosa escena boxal2. ¡Gra- 
cias por tus ánimos a Rendermanía y sigue así tú también! 


Rendermaniacos. 


Julián Pérez Serrano, un viejo conocido en estas páginas, ataca de nuevo, es- 
ta vez con un Fl 5e Eagle modelado precisamente con la misma versión 2.5 de 
Moray que hoy incluimos en el CD, Gracias por tus felicitaciones a mis casti- 
llizos virtuales y tomo nota de tu apoyo a la idea del concurso de infografía 
(aunque dicha idea aún esté algo verde, me temo) y de tu sugerencia de poten- 
ciar la búsqueda de puntos 3d interesantes en la red. Siguiendo con tu carta, 
siento decirte que tienes la negra: primero la reciente catástrofe en tu disco 
duro y luego el desastre en los flexibles que has enviado. ¡Todos tus zips daban 
errores! Afortunadamente dejaste fuera un par de imágenes que servirán para 
incluirte en el foro de hoy. Todo lo demás -tu carta al foro, los fichero md, etc.- 
no es recuperable (Sorry). En cuanto a lo que preguntas del efecto Lens Flare, 
POV no lo tiene que yo sepa pero puedes usar el de Polyray y mezclar la ima- 
gen con la de POV (ya que también te gusta trastear con programas 2D). Muy 
resultón tu cacharro. 
No dejes de leer Julián, porque Abrabawm Limpo Martínez -alias Volcano- 
, Un maquetador aficionado a los aviones quiere indicarte algunas cosillas sobre tu Fokker. Reproducimos algunas: 1) El Fokker emplea- 
ba cartucheras con cadenas de balas y las ametralladoras comenzaban con una forma cuadrada seguida de un cilindro de refrigeración. No 
llevaban punto de mira puesto que éste estaba situado entre ambas ametralladoras. 2) La caja del motor no se pintaba. 3) Las palas de la hé- 
lice eran algo más pequeñas. Esto no debe tomarse como una crítica -afirma Abraham- sino sólo como unas aclaraciones de otro gran afi- 
cionado a los aviones. 
Hablando de otra cosa, Pablo Costas nos envía un e-mail comentando que desde hace algún tiempo intenta mantener una página Web 
sobre POV en castellano. ¡Buena idea! En ella hay fags y tutoriales traducidos y se espera que siga creciendo con la aportación de todos. 
La página está en: http//www.arrakis.es/-pcostas/povray 
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Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 


figura en la segunda página de Pcmanía, o vía e-mail a rendermania.pemania O hohbypress.es 


[METAL BABES 2 
FRIO SOFTWARE 1996 


nos ha enviado de nuevo las escenas 


que en el mes anterior resultaron machacadas. Esta vez las imá- 


genes llegaron feliz- 
mente. En ellas Ri- 
cardo saca un buen 
partido de Povafx 
para renderizar los 
modelos creados con 
Moray. Hay naves 
espaciales y Casti- 
llos. ¡No os las per- 
dáis! En cuanto a tu 
pregunta, si puedes 
enviar los ficheros 
por carta en vez de 
por e-mail, la res- 
puesta es que sí. 


Os recomendamos 
que leáis en El Foro 
la carta de 

En 
ella este miembro de 
Frío software expo- 
ne que busca gente 
para crear juegos, 
gráficos, etc. 

Juan Miguel nos 
envía hoy unos mo- 
delos creados con 
3D Studio basados 
en un personaje de 
Street Fighter: Cammy. Juan admite que sus chicas aún 
no son tan buenas como las mangababes de Tomwoof 
pero “todo llegará”. Mientras tanto podéis encontrar sus 
imágenes y las 
mallas correspon- 
dientes en el direc- 
torio que lleva su 
apellido. No os per- 
dáis las caricaturas. 


es un nue- 
vo povmaniaco que 
nos envía una carta 
en la que plantea dos 
problemas principa- 
les. El primero radi- 
ca en lo incompleto 
de los manuales de 
POV. en los cuales no es extraño ver líneas “en elaboración” 
en apartados cruciales. Aquí desconocemos la fecha en que el 
Povteam se dignará completar el manual. De hecho la ver- 
sión de Dos y la de Windows tienen diferencias importantes. 
En cuanto a tus problemas para generar las escenas de casti- 
llos del número 1 de Rendermanía. los mensajes de error que 
describes son todos de falta de memoria. Como ya se indicó 
entonces, muchos de los ejemplos requerían una memoria 
considerable. De hecho cada lancero requería unos 7 megas. 
Cuando POV se queda sin Ram. intenta coger memoria del 
disco duro y el problema puede radicar en que no haya sufi- 
ciente. Hay un apartado en la pantalla de render donde se in- 
dica la memoria total que necesita POV para generar la ima- 
gen. Comprueba si este valor no es superior al de tu memoria 
libre. (Yo he generado escenas que requerían más de 80 Me- 
gabytes). Prueba a montar castillos con menos elementos —en 
el futuro intentaré que las escenas no sean tan costosas—. Con 
respecto a tu pregunta, si leiste el número anterior de este su- 
plemento, ya sabrás que POV no tiene luces flare. ¿Cómo si- 
mular este efecto? Como he dicho más arriba, una posibilidad 
sería generar el flare con Polyray (que sí tiene este efecto) y 
mezclar las escenas con alguna utilidad 2d. 
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El Foro del lector 


santes y es divertida. 


Hoy va de naves espaciales. Nuestro amigo 

nos envía otra que se desplaza sobre un bonito esce- 
nario marítimo con puesta de sol incluida. Buena es- 
cena salvo por la textura de la nave que, para ser sin- 
ceros, me ha parecido espantosa (pero sobre gustos 
no hay nada escrito). Por otro lado es cierto lo que di- 
ces acerca de las fotos del primer Rendermanía: sa- 
lieron negras y la culpa (¡Ay!) fue mía por no haber 
dado unos colores menos apastelados o no haberlas 
tratado antes de enviarlas a la Imprenta. Espero que 
no vuelva a suceder (¡sniff!). 


-alias Che- nos en- 
vía unas cuantas imágenes creadas con 3D 
Studio de las que solicita una pequeña críti- 
ca. Bien, ahí va. Me gustan el color, la at- 
mósfera y la fantasía que has conseguido en 
Alquimia, Interior y Marte (sobre todo en 
esta última escena). Parece ser que en una 
crítica anterior te dije que tus mallas eran 
muy sencillas. Quizá me expresé mal. El 
que un modelo sea sencillo no tiene por qué 
ser necesariamente malo. Todo depende del 
contexto: un modelo antropomórfico no 
puede ser sencillo -a menos que sea una ca- 
ricatura- pero una nave espacial sí puede 
serlo y quedar bien. A lo que probablemen- 
te me refería era a que necesitabas coger 
mayor soltura en el modelado, aspecto este 
en el que pareces haber mejorado bastante. 
Lo único que no me ha convencido ha sido 
la torre de la escena “naves”. Tomo nota de 
tu apoyo a Rendermanía en general y a la 
idea del concurso en particular, y transmito 
tus felicitaciones a Felix Higueras por su 
sonda espacial y a Juan Miguel González 
por sus chicas metálicas. 


pide opinión sobre su obra Vaso2. Sin 
embargo no me aclaras con que está hecha -lo cual es vital para va- 
lorarla- y tampoco envías los ficheros de generación. En fin, lo 
menos que puede decirse es que la imagen tiene detalles intere- 


es otro povmaniaco recien- 
temente enganchado a este mundillo. Nos envía su 
dos primeras imágenes —icebergs generados con 
heightfields— de las que solicita una crítica. Pues 
bien amigo Carlos, la única crítica importante está 
en la tga que has empleado para crear el heightfield 
y en la escala y disposición de éste. Como ya sabes, 
los pixels de la tga determi- 
nan la altura de la malla en el 
objeto heightheld resultante. 
Si se emplean medios algorit- 
micos para crear la tga, los pi- 
xels de los bordes no tienen 
porque diferir de los centra- 
les, con lo que la altura media 
será la misma en todos los 
puntos de la tga. Por eso, co- 
mo la altura de la malla cae a O en los bordes de la misma, el resultado es 
que, si enfocas todo el objeta como lo has hecho, verás un corte cuadrado regular bastante impro- 
pio en un objeto fractal. (Leéte la explicación que viene en “La Portada” del númerol). Lo prime- 
ro debería ser crear una tga con picos algo más suaves que la que has usado y luego escalarla ade- 
cuadamente para que no se vieran los picos externos cortados. (Las dos islitas de la portada del 
número | son un heightfield). En cuanto a tus preguntas, que yo sepa no hay planes para publicar 


un libro de la versión 3.0 de POV. El módulo spline editor de Imagine por el que preguntas (y que yo no he usado) debería servir para crear 
formas bidimensionales con curvas spline. Estas formas pueden ser empleadas luego como paths o como formas iniciales de una extru- 
sión para crear un objeto 3d. 


nos envía un disco Zip con 
una película de ciencia ficción completa montada a base 
de ficheros fli. Entre las secuencias hay combates entre 
naves espaciales, 
mechs, efectos, 
robots, etc. Hay 
buenos efectos y 
detalles y nada 
malo que decir 
sobre ella excep- 


> 


; to una cosa: 58 PES 
megas es dema- de 
a 
siado espacio pa- E 
ra nuestro CD. NA q E ES? 
Esto nos haim- Ñ 
) 


pedido, desgraciadamente, publicar la película completa, 
debiendo limitarnos a seleccionar unos cuantos ficheros 
fli. Sorry Jose María. 


ha dejado -como el mismo dice- de ser un lector 
pasivo para convertirse en un povmaniaco activo. Para demostrarlo Ju- 
lián nos envía sus dos primeras imágenes. ¿Crítica? No están mal para 
ser las primeras. El siguiente paso será practicar, practicar y practicar el 
modelado. Publicamos tu carta en el foro. Hasta pronto. 


En el CD-Rom 


Magic Camera 


Hoy presentamos un 


programa de 
egún el autor- un 
e la versión sin re- 


kunzip que creará los directorios 


20 Rendermanía 


ión registrada 


cheros. El uso del programa tampoco a 


es difícil: Pulsando sobre él aparecerá 
una ventana desde donde podremos es- 
pecificar el fichero a renderizar y las 
opciones deseadas. Desgraciadamente, 
esta es una versión limitada. La rende- 
rización de imágenes de más de 
100.000 pixels tendrá como resultado 
el añadido de una fea banda horizontal 
en la imagen. 


El programa incorpora un fichero hip E 
de ayuda que resultará más bien parco ¿ 


para alguien acostumbrado a los deta- 
llados manuales de POV y Polyray. 
Aparte de este manual, el pa- 
quete incluye tres ficheros 
que, supuestamente, nos ser- 
virán de ayuda: scan.l. que 
contiene una lista con las pa- 
labras soportadas por el len- 
guaje y expresiones validas, 
Parse.y, que contiene la gra- 
mática del lenguaje y de- 
faults.c que indica los valores 
por detecto para lo que Wes- 
nor llama sub-elementos. ¿No 


hubiera resultado más sencillo agrupar- : 


lo todo en un único fichero más com- 


pleto? ¿Por qué no se indica lo que hace : 


cada sentencia junto a la gramática? (Si 
hay un infierno, Wesnor debería ser con- 
denado a estudiar su propio doctorial.) 


Las pocas y escuetas indicaciones ¿ 


sobre el lenguaje de «Magic Camera» 
las encontraremos en el apartado “Wri- 
ting Scripts” del manual. Según parece 


el programa usa las características a ¿ 


que nos tienen acostumbrados otros 


programas; texturas procedurales, pri- 
mitivas, funciones, variables, etc. Para 
ser justos, incluso un programa como 
POV carecía hasta hace poco de algunas 
de las funciones de «Magic Camera». 
Sin embargo «Magic Camera» tam- 
bién tiene ciertos detalles de bastante e 
incluso mucho interés. Existe una sen- 
tencia, por ejemplo, con la que pode- 
mos “destruir” los objetos que ya no 


van a emplearse en una animación. 


Con esto los objetos inútiles se borra- 
rán de la memoria y podremos aprove- 
charla para otros. 

Otro punto interesante es la posibili- 
dad de definir objetos-hijo. Estos obje- 
tos se definen como “hijos” de otros. lo 
cual resulta muy útil para hacer anima- 
ciones o componer posiciones de obje- 
tos complejo. ¡Qué lo disfrutéis! 


José Manuel Muñoz 


